[Split 4/4] Run the UTS through the server door's builders - #1235

Mirrors ably-js#2297, matching the registry entries in ably-common#361:
the side flags are registered versionless (like `browser`), because under
lockstep versioning a side-flag version always duplicates the SDK entry
beside it, and across SDKs a bare version cannot say what it versions.
Identity, version and support status keep travelling on the SDK's own
ably-java/<version> entry. Wire shape:

  ably-java/2.0.0 jre/17 ably-pubsub-server

AgentHeaderCreator already emits a null-valued map entry as a bare token,
so no core change is needed; the doors stamp null and drop their
BuildConfig version plumbing. Tests now assert the flag is present as a
bare token and fail if any /version form regresses.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The family identifier follows the package split, per the agent
identifier convention proposed on PDR-091b2 and registered in
ably/ably-common#361: because it flips exactly at the split and the
maintenance branch is never touched, the identifier alone partitions
the fleet - ably-java/* is legacy-package traffic, ably-pubsub-java/*
is new-package traffic. It names the family rather than any one
published artifact; the side a client declares travels as the separate
versionless entry stamped by the door packages:

  ably-pubsub-java/2.0.0 jre/17.0.12 ably-pubsub-server

Requires the ably-pubsub-java registry entry (ably/ably-common#361)
before any release from this branch. Mirrors ably/ably-pubsub-js#2297.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Comments describe the behavior in place (versionless registry entries,
the load-bearing suffix) rather than citing decision-record or PR
numbers; those references live in the PR descriptions and READMEs.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ifier

SdkWrapperAgentHeaderTest asserts the full agent header and still
expected the pre-rename ably-java family identifier.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

PDR-091b requires core, core-android, device and server to release
together on one version, with partial release impossible:

- A verifyReleaseArtifacts task asserts the exact published artifact
  set, group and lockstep VERSION_NAME (catching module-local
  overrides), failing before anything is uploaded. The release workflow
  runs it ahead of publishAndReleaseToMavenCentral.
- A release-dry-run job in check.yml runs the pre-flight plus
  publishToMavenLocal on every PR, so coordinate and version
  regressions surface continuously rather than on release day.
- README gains a note describing the in-development 2.0 artifact set
  and that 1.x installation instructions still apply.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Mirrors ably-js#2294: the UTS constructs every client through a single
seam (TestRealtimeClient/TestRestClient in ClientFactories.kt), now
selected by the uts.side system property — `core` (default) keeps the
core constructors; `server` routes both client kinds through
PubSubServer's side-stamping builders. The builders only stamp the
side-declaring agent flag and pass everything else through (DebugOptions
included, via its copy() override), so conformance must be identical on
both legs; CI runs both for the UTS unit and integration tiers.

A harness self-test (SideModesTest, mirroring ably-js's
side_modes.test.ts) asserts each mode's stamp on the wire via the mock
HTTP engine — bare versionless flag in server mode, none in core mode —
so a broken seam cannot silently degrade the server leg into a duplicate
core run.

Unlike ably-js there is no device leg: io.ably.pubsub:device is an
Android artifact and cannot run on the JVM this suite uses; its stamping
contract is covered by the device module's instrumentation tests.

Also completes DebugOptions.copy() with the same four fields the base
ClientOptions.copy() was missing (headers, fallbackHosts,
transportParams, agents) — the door stamping relies on the polymorphic
copy() to carry the suite's mock hooks.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The UTS spec authenticates this test with a JWT; the Java port had
substituted a native TokenRequest for convenience. Restoring the JWT
(AblyJwt: HS256 via JDK crypto, no external library) lets the test carry
the signed x-ably-clientType=server claim on the server leg — the only
server-side declaration realtime accepts on token auth — so it now runs
on every leg instead of being skipped. Verified against sandbox: the
claim-bearing JWT connects and re-authenticates where the bare agent
flag was rejected with 40167.

assumeSideSupportsTokenAuth stays for the native-token tests
(TokenRequestTest): the native token format cannot carry the claim yet.

Also drops DR/ticket numbers from code comments in this PR's files;
the behavior is described in place instead.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ntifier

The family identifier shares the ably-pubsub- prefix with the side
flags, so the harness self-test now matches the side identifiers exactly
(via the Side constants) rather than by prefix, and asserts the renamed
family entry is always present.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

TokenRequestTest's two clients now sit on opposite sides of the seam,
matching how native tokens are really used: the minting client — the
createTokenRequest surface under test — goes through the door on every
leg, so the server leg exercises token minting through the server
package; the consuming client models the device the token was minted
for and is always a plain core client, since a client may not
authenticate itself with a native token while declaring the server side
(realtime rejects that with 40167, and the native token format cannot
carry the required signed claim).

Nothing is skipped on any leg any more, so assumeSideSupportsTokenAuth
is deleted.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>